All committers have signed the CLA.

I'm a little concerned about the name of the function. It sounds like an adjective to me. (We discussed this topic in #1098 )

Does anyone have any other suggestion for the name of this?

I'm a little concerned about the name of the function. It sounds like an adjective to me. (We discussed this topic in #1098 )

Does anyone have any other suggestion for the name of this?

Kotlin calls it single, hence the initial name . I personally see why, it reads well when used in context. Maybe getSingle is an alternative? Or only? getOnly? getOnlyElement? onlyElement? :-S

@kt3k I think this is approaching mergability - what should we do about the name?

@LionC

what should we do about the name?

I started feeling the name is ok as is because single seems having noun usage.

Does anyone have any opinion about this? cc @timreichen

@kt3k
I think single is not a good name, firstly because it is not a verb and secondly because it is not descriptive at all on what it does.
Since we have a distinct and distinctBy, how about findDistinct?

@kt3k
I think single is not a good name, firstly because it is not a verb and secondly because it is not descriptive at all on what it does.
Since we have a distinct and distinctBy, how about findDistinct?

If you read

const file = findDistinct(Deno.args)

do you feel like you would know what's going on here?

In my (non-native speaker) mind the word distinct needs other values to make sense and does not really make sense for a one-element array.

@timreichen Thank you for the input, but findDistinct sounds a little strange to me..

How about findSingle?

@kt3k This will make deno std attractive for people that do partnership search:) I don't know, but better than just single still not really expressive imo.
@LionC

const file = findDistinct(Deno.args)

tbh not so much since the default predicate is set to (_) => true (which I don't know is a good idea if we use find as the verb as in js find and findIndex have a mandatory predicates?).

In that sense I think having this default predicate changes the meaning of the function to Deno.args.length === 1 ? Deno.args[0] : undefined where with a custom predicate it is about finding a distinct value in an array.

const value = findDistinct(["f", "o", "o"], (char) => char === "o") // undefined

const value = findDistinct(["f", "o", "o"], (char) => char === "f") // "f"

btw:
not sure about this check:

if (match !== undefined) return undefined;`

Hypothetically this will not short circuit for undefined values:

const array = new Array(1000).fill(undefined)
const value = findDistinct(array, (i) => i === undefined); // predicate called 1000x

Maybe a flag should be used instead?

let match: T | undefined = undefined;
let found = false
for (const element of array) {
  if (predicate(element)) {
    if (found) return undefined;
    found = true
    match = element;
  }
}
return match;

@timreichen

@kt3k This will make deno std attractive for people that do partnership search:)

Adoption boost spotted^^

tbh not so much since the default predicate is set to (_) => true (which I don't know is a good idea if we use find as the verb as in js find and findIndex have a mandatory predicates?).

Yeah that is what I meant - find does not fit that well but it is an essential part of the usage/signature (stolen from kotlin again).

Hypothetically this will not short circuit for undefined values:

const array = new Array(1000).fill(undefined)

const value = findDistinct(array, (i) => i === undefined); // predicate called 1000x

Oh yes, we should change that @NotFounds . Good catch!

@timreichen
Thank you for your review and suggestion.
I didn't take that case into consideration...

Fixed it! 8864057

Should be mergeable now @kt3k

Can we settle on the name 'single'?

@NotFounds Do you have any preference on naming?

(I'm not a native speaker)
I'm comfortable with the use of "single".
And especially when the behavior is the same as the method used in other languages.

But... if a verb is preferred, the suggested "findSingle" is the best fit for me.

findSingle?

Sounds like single and findSingle are the options. I would vote for single because it is short :-)

@kt3k I think we need your/some core call here.

Note

NotFounds: single or findSingle
Leon: single
Luca: findSingle
Tim: findDistinct
Grian: single or findSingle
Yoshi: single or findSingle

(new votes are welcome!)

@kt3k
I would join the findSingle crew if we removed the default selector (reasons why described above)

I dont think we should remove functionality for a name, but find a name for functionality

I think findSingle or findDistinct describes the algorithm of the function pretty well. So I argue that it is not removing functionality but removing a bad default that changes the intent of the function. Consider findSingle([]), findSingle([undefined]) and findSingle([undefined, undefined]): The return values will be undefined for all of them with the current default predicate, making the intended usage of this function questionable. That default predicate might make sense in kotlin because it throws an exception if it is not successful. Because this implementation returns undefined on failure that predicate is not really useful imo.

To make sure a single value exists in an array array.length === 1 should be used instead of that function anyhow, so why not generalize it by removing the predicate therefore solving the naming problem too?

I think findSingle or findDistinct describes the algorithm of the function pretty well. So I argue that it is not removing functionality but removing a bad default that changes the intent of the function. Consider findSingle([]), findSingle([undefined]) and findSingle([undefined, undefined]): The return values will be undefined for all of them with the current default predicate, making the intended usage of this function questionable. That default predicate might make sense in kotlin because it throws an exception if it is not successful. Because this implementation returns undefined on failure that predicate is not really useful imo.

Typings make that undefined case pretty clear I think - I can not come up with any bugs that could cause, but maybe I am missing them. It is really similar to an index access returning undefined vs that index's value actually being undefined.

To make sure a single value exists in an array array.length === 1 should be used instead of that function anyhow, so why not generalize it by removing the predicate therefore solving the naming problem too?

I mean you can always write more code instead of using something that encapsulates it, sure. Saying "should" here is a stretch to me though - why "should" someone not use that function if they want to? It might not be your style, but it might be theirs and it is hard to say someone objectively "should" not do it.

Either way, I think I would be fine with findSingle the way it is right now if that is what it takes to get this merged^^ So @kt3k you can consider me in the "single or findSingle" camp as well :-)

Let's settle on the name findSingle because everybody is at least OK with it.

Let's continue the discussion of the default selector in another issue.

I'm merging this for now as this one is enough discussed and looks having enough quality now. Thank you for your efforts!